1. Field of the Invention
This invention is related to processors and, more particularly, to the monitoring of cache lines for changes.
2. Description of the Related Art
Many application programs are written to interact with other application programs. Additionally, many application programs are written as multi-threaded applications. Multi-threaded applications have multiple code sequences (threads) designed to execute relatively independently. The threads (or applications) may communicate with each other in a variety of ways. For brevity, the term “thread” will be used in this discussion to refer to a code sequence from a multi-threaded application or to refer to an application as a whole, if the application is not itself multi-threaded.
Memory locations are often used to communicate between threads. For example, a memory location may be defined to store a semaphore used to control access to a larger area of memory, control access to another resource in the computer system such as a peripheral device, control the ability to execute a particular code sequence (often referred to as a “critical section”), etc. Any of the above will be referred to as a protected resource below. Typically, a thread may access the semaphore and check its state. If the state indicates that the thread may take control of the protected resource, the thread may change the semaphore state to indicate that the thread controls the protected resource. If the state indicates that another thread is in control of the protected resource, the thread may continue checking the semaphore until the state changes (e.g. by the other thread writing the semaphore to indicate that it is done with the protected resource). Memory locations may also be used to pass other messages between the threads (or to indicate that a message is available). If a given thread is awaiting a message from another thread, the given thread may continue checking the memory location until the memory location is written with a value indicating that the message is available. Many other examples exist in which a thread uses memory locations to communicate with another thread.
Typically, when a thread is checking a memory location for a desired state and does not find the desired state in the memory location, the thread enters a “spin loop” in which the thread repeatedly accesses the memory location checking for the desired state. When the memory location is eventually written with the desired state, the thread may exit the spin loop. While the thread is in the spin loop, the thread is not really accomplishing useful work. However, the processor that is executing the thread is consuming power executing the spin loop.
Some instruction set architectures have defined instructions that permit the processor to optimize for such situations, if the programmer uses the instructions in spin loops and other cases in which a thread is awaiting a desired state in a memory location. For example, the ×86 instruction set (with the streaming single-instruction, multiple data extensions 3, or SSE3) defines a MONITOR/MWAIT instruction pair. The MONITOR instruction can be used to establish an address range that the processor is monitoring for an update (e.g. due to a store executed by another processor). The MWAIT instruction can be used to cause the processor to enter an “implementation-dependent optimized state” while waiting for the update. The processor exits the implementation-dependent optimized state in response to a store in the monitored address range (and also for certain interrupts and other reasons not related to the monitored address range). Typically, the processor is informed of the update through the normal coherency mechanism implemented in the processor.